如何写出有效的单元测试

什么是单元测试

《单元测试的艺术》中对单元测试的定义：

一个单元测试是一段自动化的代码，这段代码调用被测试的工作单元，之后对这个单元的单个最终结果的某些假设进行校验。

单元测试几乎都是用单元测试框架编写的；只要产品代码不发生变化，单元测试的结果是稳定的。

为什么需要单元测试

在我看来，单元测试的意义可以总结如下三点：

• 单元测试是保证你写的代码是你想要的结果的最有效办法
• 单元测试帮我们塑造设计
• 单元测试是最好的文档之一

单元测试描述了代码的预期行为，可以最有效地保证代码正确运行，减少代码缺陷；由于单元规模较小，当因为代码变更出现问题的时候，可以帮助我们快速定位问题；有单元测试覆盖的代码，让我们更有信心，敢于放心做代码重构；

写单元测试的过程往往伴随着代码重构，如果发现一段代码单元测试很难写，就需要反思我们的设计，进而重构促进代码设计的优化，帮助我们塑造设计；

同时单元测试也是一个最佳的、自动化的、可执行的文档；没有单测覆盖的代码，是很难被维护的。

什么是有效的单元测试

可读、可维护、可信赖、快速执行！

《单元测试的艺术》中描述优秀单元的特性：

它应该是自动化的，可重复执行；
它应该很容易实现；
它应该第二天还有意义；
任何人都应该能一键运行它；
它应该运行速度很快；
它的结果应该是稳定的（如果运行之间没有进行修改的话，多次运行一个测试应该总是
返回同样的结果）;
它应该能完全控制被测试的单元；
它应该是完全隔离的（独立于其他测试的运行)；
如果它失败了，我们应该很容易发现什么是期待的结果，进而定位问题所在。

可读性

“一般程序员写得出计算机能读懂的代码。优秀程序员写得出人能读懂的代码” — 马丁·福勒

可读的代码才是可维护的；难以阅读和理解的测试用例，最终的结果就是删掉它，因为维护成本过高。可读性高于纯粹的性能。

可维护性

团队内使用一套范式的结构，有助于使之更好用，快速定位问题；消灭代码中的坏味道。

可信赖

可信赖的含义：

1. 测试可重复；

2. 测试与依赖环境隔离；

3. 只测试不进行验证是不可靠的测试；

4. 在测试类中不要依赖与测试的顺序；

5. 测试的结果是精准的：校验的精准以及错误问题的精准定位；

快速执行

保证单测快速执行，缩短反馈时长；

为什么有效的单元测试如此重要

无效的单元测试是没有意义的，反而会增加维护成本，最终导致单元测试的失败！

如上图所示，坐标中任意一个点，其与横纵坐标垂直线所形成的矩形面积代表CI为团队带来的价值，那么在我看来有两个关键的因素：横坐标是单元测试的基础能力建设，纵坐标则是有效的单元测试；

没有有效的单元测试，基础能力做出花来也毫无意义！完善的基础能力同时也帮助我们更低成本的写出有效的单元测试。

如何写有效的单元测试

我们以Flutter为例，来一起讨论如何写有效的单元测试；

使用测试框架

Flutter官方提供的测试框架：

• flutter_test

• integration_test

统一的编码约定

不论是AAA（Arrange-Act-Assert）还是GWT（Given-When-Then），统一的编码约定帮助保证测试代码的可读性、可维护性。

使用测试替身

测试替身帮助我们隔离被测试代码，加速执行速度，保证测试代码是可信赖的；

• Dummy：一种什么也不做的实现方式。接口中的每个方法什么也不做，如果方法有返回值，返回的值尽量接近null或者0。

• Stub：Dummy的一种，Stub的函数并不返回null或0，而是返回能推动函数沿预定路径被测试的值。

• Spy：Stub的一种，它返回测试所需的特定值，推动系统沿着我们期望的路径前行。然而，Spy能记住对它所做的事，并允许测试询问。

• Mock：Spy的一种，它返回测试所需的特定值，推动系统沿着我们期望的路径前行，而且还会记住对它所做的事。不过，Mock还知道我们的预期，基于这些预期，判断测试是否通过；换而言之，Mock中写明了测试断言。

• Fake：Fake是一种模拟器，它实现基础业务规则，这样测试就能要求该Fake按需要的路径执行。

一个测试应当只检查一件事

明确测试意图，一旦出错可以精准定位问题；

一个测试只有一个模拟对象

避免过多模拟对象，一个测试用例的校验内容尽量简单；

避免冗余测试

冗余测试会提高维护成本；

避免条件逻辑

条件逻辑会让你的单元测试更难以维护，出问题不容易排查，不够精准；

单测需要确定性

避免脆弱测试，Mock不确定的依赖：时间、随机数、并发性、基础设施、现存数据、持久化、网络等等；

测试快速执行

避免sleep等操作，导致测试执行缓慢；

避免过度指定

对于过度指定的讨论，其核心问题就是要我们判断哪些是单元测试应该覆盖的，哪些是应该留给其他测试手段的。如果一个场景，单元测试覆盖之后，导致经常单测失败，需要不断更新维护，那就可以考虑不做单元测试覆盖。

像素完美是一个典型的、经常拿出来讨论的例子，Flutter的Golden Test就是一个golden master testing的例子；《有效的单元测试》中关于像素完美的讨论：

像素完美：顾名思义，是一种特定于图形和图像生成的测试坏味道。它混杂了魔法数字和基本断言，使得测试极难阅读也极其脆弱。

这种测试几乎无法阅读，因为即使测试在语义上是处于高层概念的，却仍然会针对硬编码的底层细节例如像素坐标和颜色来进行断言。指定坐标上的像素是黑还是白，与两个图形是否相连或堆叠的概念是有区别的。

这种测试极其脆弱，因为即使很小的和不相关的输入变化——是否是另一个图像，或图形对象的渲染方式——都足以影响输出、打破测试，谁让你非要精确地检查像素坐标和颜色呢。同样的问题在采用golden master技术时也会遇到，其做法是事先将图像录制下来，并手工检查其正确性，以后再进行测试时就将渲染出的图像与之进行比对。

这些可不是我们愿意去维护的测试。我们不希望带着这种脆弱的精确度去编写测试，而是使用模糊匹配和智能算法来代替繁琐的数值比较。

对于特定场景，Golden Test是一个非常有效的手段，但需要非常谨慎的评估；慎用Golden Test！

不要写永不失败的测试，不要写没有校验的测试

单测需要对明确的逻辑校验，永不失败的测试或者没有校验的测试是不可信赖的。

测试不要名不副实

避免测试的描述与测试内容不符；测试结果必须精准；测试该失败的时候一定要失败！

测试私有或者受保护的方法

解决思路：

1. 将方法变成公共方法；

2. 将方法抽取到新类；

3. 将方法变成静态方法；

4. 将方法成为测试可见方法；

避免强制的测试顺序

依赖测试顺序导致测试可靠性变得脆弱，未来维护成本变高；

清理测试环境

在teardown阶段清理测试环境，例如还原全局的Config、清理创建的文件目录等等；

统一的单测命名、变量命名

统一的单测命名可以提高可读性、可维护性；

使用有意义的断言

断言的错误信息要有意义，出现问题能够明确错误的原因；

把单元测试视为“一等公民”

测试用例应该被视为“一等公民”：同样需要代码评审，同样需要代码质量检查，确保单元测试的有效性；

单元测试代码评审的过程，也是团队同学互相学习的过程，沉淀最佳实践的过程。

加速执行速度

日常对单测执行时间进行监控，对测试进行性能分析，优化执行时间过长的测试用例。

测试金字塔

测试金字塔是Mike Cohn在他的著作《Succeeding with Agile》一书中提出了这个概念。测试金字塔是一个比喻，它告诉我们要把软件测试按照不同粒度来分组。它也告诉我们每个组应该有多少测试。

为了维持金字塔形状，一个健康、快速、可维护的测试组合应该是这样的：写许多小而快的单元测试。适当写一些更粗粒度的测试，写很少高层次的端到端测试。注意不要让你的测试变成冰淇淋或者沙漏那样子，这对维护来说将是一个噩梦，并且跑一遍也需要太多时间。

避免测试重复

在实现测试金字塔时，你也应该牢记这两条基本法则：

1. 如果一个更高层级的测试发现了一个错误，并且底层测试全都通过了，那么你应该写一个低层级测试去覆盖这个错误；

2. 竭尽所能把测试往金字塔下层赶；

如果你已经在低层级测试里覆盖了所有情况，那么再维护一个高层级的测试就没有必要了。警惕沉没成本的思维陷阱，果断摁下删除键。没有理由在不再提供价值的测试上浪费宝贵时间。

补充单元测试应该从哪里开始

单元测试应该及时编写，就算没有实践TDD，也应该在代码实现之后尽快编写单元测试，避免写出不可测试的代码，也可以让bug尽早暴露；

但很不幸的，我们很多时候在刚开始卓越工程，推广单元测试的时候，不得不面对补充单元测试的情况；这绝对是一个有挑战的事情。

补充单元测试应该从哪里开始？参考测试金字塔，对于基础组件库来说，可以根据具体情况来定；

对于业务库来说，第一步建议从金字塔顶端的测试：

• 优先覆盖回归测试用例中P0级别的用例；

• 避免过度指定的端到端测试；

• 适当的契约测试；

接下来，从金字塔中间层开始，不断向上、向下补充；

可测试的设计

应当容易、快速地为一段代码编写单元测试；可测试的设计，使我们写出模块化的设计；

行动指南

为了写出可测试的代码，需要注意以下几点：

1. 避免复杂的私有方法；

2. 避免final方法；

3. 避免static方法；

4. 使用new要当心；

5. 避免构造函数中包含逻辑；

6. 避免单例；

7. 组合优于继承；

8. 避免服务查找；

9. 基于接口的设计；

可测试的代码是否违背了SOLID中的开闭原则？

可测试的代码设计，有的时候需要避免复杂的私有方法或者受保护的方法，因为这些意味着不可测试；

这样的话是不是意味着可测试的设计违反了开闭原则呢？

在代码重构的时候，可以认为给对象模型增加了另外一种最终用户——测试用户。

另外如果一部分代码实在不希望暴露，也可以使用@visibleForTesting 修饰；

单元测试与重构

写单元测试的过程往往伴随着重构；代码重构同样需要单元测试保证代码正确运行。

重构需要遵守的纪律：无测试重构无意义，频繁重构、果断重构、坚决重构；

持续重构

将麻烦扼杀在摇篮；

果断重构

敏捷编程的名言之一。规则很简单：重构时要勇敢。勇敢尝试，勇敢修改，不用害怕代码。

让测试始终能通过

建一个绿色安全区，不允许破窗出现。

留条出路

仓库打好tag，以便在需要的时候能够回滚。

可测试的代码

可测试的代码就是解耦了的代码；可测试的代码帮助我们实现更好的抽象。

做不到TDD，可以做到测试先行

下图是遵循TDD三大法则的实践过程；TDD很强大，但不一定适用所有的团队，推广难度很大，学习曲线很高。

TDD事实上由两个方面组成：测试先行，以及演进式设计；测试先行是非常重要的工程实践，做不到TDD，可以做到测试先行。

在Kent Beck的经典名著《解析极限编程》中，提到：尽早测试，经常测试，自动测试！

测试先行的本质能力要求是接口的设计能力——能否清晰的定义出设计单元的边界。

如何理解单元测试代码覆盖率

不要把它们变成管理的指标。
这就是你使用覆盖率数字的目的：使用它们作为衡量标准来帮助你改进，而不是用它们作为惩罚团队和使构建失败的棍棒。 ——《匠艺整洁之道》

代码覆盖率的一大忌讳：为了追求代码覆盖率，只测试不进行验证；

一味追求代码覆盖率，往往写出无效的单元测试，额外增加了维护成本，最终不得不放弃以失败告终。

与其追求代码覆盖率，不如将重点关注在确保写出有意义的测试。

沉淀最佳实践

必须承认单元测试有一定的成本，成本曲线来看，前期比较高；恰恰是这前期的门槛，让很多人望而却步。在团队内推广的时候，最难的就是写出第一个单元测试；

我们需要沉淀最佳实践，帮助降低写单元测试的成本，让我们更容易地写出有效的单元测试。

我觉得沉淀最佳实践最好的方法，就是Code Review；正如我们前面所说的，要把单元测试当成是“一定公民”，在Code Review的过程中，互相学习、分享最佳实践，消除无效的单元测试。

隔离单元测试与集成测试

集成测试是对一个工作单元进行的测试，这个测试对被测试的工作单元没有完全的控制，并使用该工作单元一个或多个真实依赖，例如时间、网络、数据库、线程或随机数生成器等。

任何测试，如果它的运行速度不快，结果不稳定，或者要用到被测试单元的一个或多个真实依赖，就是集成测试。

在日常开发过程，我们需要建一个绿色安全区：单元测试与集成测试隔离；

集成测试不够稳定，运行时间长等问题，如果不做隔离，日常开发浪费时间和精力维护，最后导致开发人员不再信任测试。

单元测试与ABTest

单元测试与ABTest有什么关系吗？事实上没有什么关系。但一定程度程度上，它们本质是相同的，都是保障线上代码质量（当然单测的成本，对于基建、开发者的能力的要求更高）；

在日常开发中，经常主动为新的代码逻辑增加AB开关，一旦线上出问题留一条后路；发生问题的时候往往感慨AB开关救我一命；

单元测试可以让问题左移，防止问题上线，同样是一道保护；

如果有一天团队同学愿意主动增加单元测试来保护自己的代码，那么单元测试这件事就算比较成功了。

写在最后

从软件工程到卓越工程，单元测试从可选变成了必要；想要实现主干开发、大库模式，单元测试是前提条件。

关于单元测试这件事，我觉得最重要永远是写单元测试的人，优秀的团队文化非常重要，没有什么能够真正衡量单元测试做的好坏，有的只是程序员的职业操守。

我们花了很大的篇幅讨论有效单元测试的重要性以及如何写出有效的单元测试，不得不承认单元测试有一定的成本，真正实践依然需要很多的路要走，需要我们在实践中定义好单元测试的边界，找到最适合团队的最佳实践。

参考文档

• 《单元测试的艺术》
• 《有效的单元测试》
• 《Succeeding with Agile》
• 《匠艺整洁之道》
• The Test Pyramid：https://martinfowler.com/articles/practical-test-pyramid.html
• Software Engineering at Google：https://qiangmzsx.github.io/Software-Engineering-at-Google/#/zh-cn/Chapter-12_Unit_Testing/Chapter-12_Unit_Testing